對於許多與極端程式設計接觸不深的人來說，似乎極端程式設計主張軟體設計的消亡。不僅許多設計活動被嘲笑為「龐大前期設計」，連 UML、彈性架構，甚至模式等設計技術都被輕視或直接忽略。事實上，極端程式設計包含許多設計，但它以不同於既有軟體流程的方式進行。極端程式設計透過允許演化成為可行設計策略的實務，讓演化設計的概念重獲新生。它也提供新的挑戰和技能，因為設計人員需要學習如何進行簡單設計、如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式。

在過去十年中，我們開發並改進了許多技術，讓資料庫設計可以在應用程式開發時演化。這對於敏捷方法來說是非常重要的功能。這些技術仰賴於將持續整合和自動化重構應用於資料庫開發，以及資料庫管理員和應用程式開發人員之間的密切合作。這些技術適用於生產前和已發布的系統，以及全新專案和舊有系統。

當組織面臨需要更換現有軟體系統時，通常會陷入技術更換半途而廢的循環。我們的經驗教導我們一系列模式，讓我們可以打破這個循環，這些模式仰賴：明確認知取代舊有軟體的預期成果、將此取代分階段進行、逐步交付這些階段，以及改變組織文化，認知到變更是不變的現實。

架構不一定要是獨白，由少數集中管理者從上而下傳達。本文描述另一種執行架構的方式，以一系列對話為基礎，由分散且賦能的決策技術驅動，並由四種學習和調整機制支援：決策記錄、諮詢論壇、團隊來源原則和技術雷達

近年來，關於無架構資料優點的討論越來越多。無架構是對NoSQL 資料庫感興趣的主要原因之一。但無架構涉及許多細微差別，無論是在資料庫或記憶體中資料結構方面。這些細微差別存在於無架構的含義以及使用無架構方法的優缺點中。

最近，我的同事 Neal Ford、Rebecca Parsons 和 Pat Kua 合著了一本名為「建置演化式架構」的書。我感到很榮幸他們邀請我撰寫前言。

任何讀過我文章的讀者都知道，我是演化設計的忠實支持者。儘管我熱衷於此方法，但沒有任何技術是完美的，我樂於報告其問題，就像我樂於報告其成功一樣。

資產擷取是一種開發StranglerFigApplication的策略。您可以將許多應用程式視為管理一組關鍵資產。薪資系統負責員工，交易系統負責交易，租賃系統負責租賃。若要逐步切換到新系統，您可以從識別您將從新系統開始的一組資產開始。通常，最適合開始的資產是簡單資產（因為它們可以快速啟動）或那些舊系統特別難以處理的需求。

設計軟體是否值得花費力氣？

領域驅動設計是一種軟體開發方法，其開發重點在於編寫一個對領域的流程和規則有深入了解的領域模型。此名稱來自 Eric Evans 於 2003 年撰寫的一本書，該書透過一系列模式來描述此方法。從那時起，一個由實務工作者組成的社群進一步發展了這些想法，衍生出各種其他書籍和訓練課程。此方法特別適合複雜的領域，其中需要組織許多通常很混亂的邏輯。

SOA 是否可以使用敏捷方法來完成？

當我聽到團隊使用微服務架構的故事時，我注意到一個常見的模式。

1. 幾乎所有成功的微服務故事都始於一個過於龐大而被拆分的巨石
2. 我聽說過幾乎所有從頭開始構建為微服務系統的系統案例，最終都遇到了嚴重問題。

這種模式導致我的許多同事認為，即使你確定你的應用程式夠大，值得這樣做，也不應該使用微服務啟動新專案。。

在許多組織中，預期任何持續性資料都將儲存在由中央資料庫管理小組管理的關係資料庫中。這種中央控制有各種原因，通常集中在使用 IntegrationDatabases。中央資料小組擔心排除格式錯誤的資料、會減慢重要共用資源的查詢，以及整個企業中一致的資料模型。

這些目標可能是值得的，但其中一個後果是儲存資料的儀式相當繁瑣。我經常聽到關於變更訂單的抱怨，這些訂單需要數週才能將欄位新增到資料庫中。對於習慣於短週期演化設計的現代應用程式開發人員來說，這種儀式太慢了，更別說太煩人了。

因此，應用程式開發小組告訴我使用 NoSQL 資料庫 來繞過資料庫管理員。他們使用的是「純粹資料儲存庫」，而不是「適當的資料庫」，這很有幫助。這樣一來，資料庫管理員就可以被排除在外，通常不會被告知或樂於不關心。

對影響其所有使用者的介面進行變更需要兩種思考模式：實作變更本身，然後更新其所有用法。當你嘗試同時執行這兩項操作時，這可能會很困難，特別是如果變更是在具有多個或外部客戶端的 PublishedInterface 上。

平行變更，也稱為擴充和收縮，是一種模式，可以安全地實作介面的向後不相容變更，方法是將變更分成三個不同的階段：擴充、遷移和收縮。

你坐在會議中，思考著團隊過去幾年來編寫的程式碼。你決定現在能做的最好的事情，就是拋棄所有程式碼，並在全新的架構上重新建構。這讓你對那些註定失敗的程式碼、你花在上面工作時間，以及你過去所做的決定，有何感想？

在物件導向的早期，像我這樣的 OO 倡導者非常重視爭論重複使用的優點。早期我們討論重複使用類別。然後我們發現，重複使用個別類別在某些情況下有效，但在其他情況下卻不盡然。因此，我們開始使用可重複使用的架構，這讓我們獲得了部分建構的功能應用程式。

使用網路服務的其中一個好處是，它有助於你將系統的各個部分解耦。人們可以在一定程度的分離下，使用不同的程式碼庫工作。雖然你可以獲得一些解耦，但你無法完全消除耦合，因為服務仍然必須透過其介面彼此通訊。令人遺憾的是，許多團隊讓這種耦合變得比它應該的還要糟糕。

Yagni 最初是一個縮寫，代表「你不需要它」。這是一個來自 極端程式設計 的口訣，通常在敏捷軟體團隊中廣泛使用。這是一個聲明，表示我們假設軟體在未來需要的一些功能不應該現在就建構，因為「你不需要它」。